home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Amiga Plus 1995 #5 & #6
/
Amiga Plus CD - 1995 - No. 5 and 6.iso
/
pd
/
grafik
/
superviewel
/
superviewlibrary
/
docs
/
svsupport-docs
/
cpinfoformat.doc
< prev
next >
Wrap
Text File
|
1995-08-02
|
8KB
|
188 lines
The ControlPadInfo-FileFormat V6.4 (30.4.95)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Some applications might wish to enable the user to interactively
specify controlpad settings just when reading, writing or
processing an image and not before or after by setting preferences.
Until this will be managed by superview.library, superviewsupport.library
or the single modules by introducing new functions for handling this,
applications may take this information from ".cpinfo" files, where
the specific ControlPad entries are dynamically described.
Every CPInfo-File is constructed like an usual ControlPad file,
but in this case, the _order_ of the entries becomes meaningful.
These files are separated into SECTIONs, where any necessary
information about specific ControlPad entries are stored.
To allow easy enhancements and improvments on this format, there's
an important note:
- the number of sections is not limited
- each SECTION _must_ contain at least the entries described below
- each SECTION _may_ contain more entries, so that it might be
necessary to skip all the following entries until another "SECTION"
entry will be reached
- the order of the entries is _fixed_
- if any of the following _needed_ entries makes no sense,
it will still be present as a "dummy", thus just a Keyword
is placed there and no value is given via "="
A CPInfo-File has the following structure:
CPINFO ; identification
SECTION=<Name of ControlPad entry> ; the name of the entry
TYPE=<INTEGER|FLOAT|ASCII|NONE> ; type of data, signed or
; unsigned might be detected
; via min and max.
; NONE is used for KeyWords.
MIN=<Value> ; - minimum value for numbers
; - minimum length for strings
; - or empty ("MIN")
MAX=<Value> ; - maximum value for numbers
; - maximum length for strings
; - or empty ("MAX")
DEFAULT=<Default value for entry> ; what will be used if nothing
; is specified ?!
; May be empty, if optional.
DESCRIPTION=<descriptive text> ; what does it do ?
MASK=<input mask> ; this one allows to separate
; choices and "free" enterings
WHEN=<READ|WRITE|ALWAYS|PREFS|NEVER> ; ask for it, when the user
; does reading or writing
; (SVObjects) ? Or always
; (SVDrivers/SVOperators) ?
; Or never ? (Undocumented)
; Or Just handle it as a real
; preferences thing ?
A few words to the MASK entry:
Any entries which don't have a specific meaning (just comments)
or mutual exclude entries do have to begin with "<" and end with
">". Anything else are control sequences, qhich either are
to be supported or have to be ignored.
a) "<...>" or "<...|...|...>"
Usually you should print out this text as a little help for
the user, how to enter the data, e.g. into a string/integer gadget.
But if the string included by "<" and ">" does contain one or
more "|" these are meant as exclusice choices, which e.g.
might be represented as mx-, cycle- or listview-gadgets.
So you may a) present this mask to the user while editing a
string/integer gadget or b) parse it and just "filter" the input
via supplying appropriate input gadgets.
Please note, that the "MIN" and "MAX" values (if specified)
still have to be valid for this input (if the file definition
has been done correctly ;-)
So for a "MASK=<8|24>" these would equal "MIN=8" and "MAX=24".
But note, that this "mask" is not really meant to define ranges
with gaps, like "anything between 5 and 37, but except the numbers
between 33.3 und 36.5" 8-)
b) Control Sequences
MASK=_SVOBJECT means, that a file from "LIBS:svobjects"
has to be requested, which matches
"#?.svobject".
MASK=_SVDRIVER means, that a file from "LIBS:svdrivers"
has to be requested, which matches
"#?.svdriver".
MASK=_SVOPERATOR means, that a file from "LIBS:svoperators"
has to be requested, which matches
"#?.svoperator".
MASK=_FILE a file to be selected e.g. fromout a
requester (it is supposed, that the user
does the right choice).
Well, so an entry for a KeyWord might look like this:
SECTION=ANYDATATYPES
TYPE=NONE
MIN
MAX
DEFAULT
DESCRIPTION=Switches Datatypes support to ANY
MASK
WHEN=PREFS
An entry for a float value:
SECTION=SCALE_FACTOR
TYPE=FLOAT
MIN=0.1
MAX=2.0
DEFAULT=1.0
DESCRIPTION=Factor for scaling graphics
MASK=<Value>
WHEN=ALWAYS
An entry for an ASCII text:
SECTION=PACKMETHOD
TYPE=ASCII
MIN=4
MAX=4
DEFAULT=NUKE
DESCRIPTION=How to pack the written data
MASK=<XPK-Packer>
WHEN=WRITE
An example for an ignoreable Keyword:
SECTION=DEBUGMODE
TYPE=NONE
MIN
MAX
DEFAULT
DESCRIPTION=Enables debugging mode with Confirm-Requesters
MASK
WHEN=NEVER
So you see, that it's easy to describe any of the existing ControlPad
variations this way.
The "WHEN" statement is just a help for applications to decide, whether
requesting any specific entry would _really_ be useful to the user
(BTW: the user should always be able to deactivate any kind of
automatic requests. Maybe add sort of an "expert mode" for
those stuff).
Future:
A. First "maybe" (most likely)
In the future, there might be a function in superview.library, which
allows passing a controlpad list to it, which then might be passed
to the attached SVObject/Driver/Operator as a "local" setting,
which will override the "global" ControlPad files.
So the CPInfo Files would be useful for the applications on how
to find out, which ControlPads might be possibly set.
B. Second "maybe" (my former favorite idea: no longer)
Also there might be a way to allow superviewsupport.library
to "filter" any incoming ControlPad entry.
If it's content is equal to the KeyWord "REQUEST"
(e.g. "DITHERMODE=REQUEST"), the library might read the CPInfo-File
and then open a requester asking for an appropriate value.
This would be again a global setting, but would also work with
older superview-based applications sine no new functions are needed
(but applications, which don't use superviewsupport.library for
ControlPad-parsing would lose at this point).
C. Third "maybe" (unlikely, since it would restrict applications too much)
superview.library might parse the CPInfo-Files for specific modules
and ask for values, if it comes to the conclusion, that it's
necessary ("WHEN" statement).
If you're an application programmer please let me know, what's your
favoured idea.
Work is still in progress, nothing's fixed.
- Andy